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ABSTRACT 


This thesis examines the various functional modules that 
have been designed in supocrt of tha Stock Point Logistics 
Integrated Communications Environnant (SPLEce} local 
computer network. Initially, the svarali design methodclogy 
meompiesenl -ed,)) DOLLOwed soy a description of the functional 
moiules, their proposed capabilities and their relationships 
to e€ach cther. Finally, an analysis is made to datermine how 
well the medules Fit togather +o form an operational iocal 
SONpuece= TMetwOrk and tO SUpport both inter- and intzra- 


network communications. 
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Ae. GENERAL OVERVIEW 


The information contained in this section was obtained 
from a series of referenc2 documents produced by both Naval 
Supply Systems Ccmmand (NAVSUP) Ander les Saiiiewer ial Guoper: 
Office (FMSO) and is included as background [Refs.1,2,3 ].- 

PicwotCeKesFOlnt ~bogiecics Integrated coamunZications 
Environment (SPLICE) project is being developed to augment 
wee reec mg Navy Stock Point ani Laventory control Poins 
MOPerect l= cs that support the Jniform Avtomated Data 
Processing SystemStock Points (UADPS-SP). 

Presentiy, there ace twenty new applications systems in 
various stages of development which will requir? a consider- 
abl2= amount of interactive processing and teleconmunications 
SUDDOL=. Pies CUPSen: GUADPS-SP hirtdware@e-:is a Bu=roedghs 
Medium Size (B-3500/3700/%7 00/4800) SyStem, Witchewa!l nor 
be able +o support these requirements without 2a total rede- 
Sign efrort and possible niinframe rzplacement. HOesulp DORs 
the Smaueraciive and telecommurications capabilitis 
Ceqgueted, sidividual project managers for the new applica~ 
PoP soeevecems development wlil be itilizing a varisty of 

nicomputers. These syst2ms will all be implenented within 
cas Pekecwe tour Beometave years according nO OLOjJeectoa 
schedules. 

The development of SPLICE will iave two na 
Powe i) Mec. fhe increased need for the use o£ CR 
SerNeda’S TO 2ncebact with appiization logic ander 
Gmeormet:onr from the sSysten data base and it will aiso 
address the need for a standard tel2processing hardware and 


fe 


software environn SO S82 PpOLt che Many new pbojec ~s =hac 








will impact all Navy UADPS-SP sites. Tals Se2n deen -Zeson 
will provide major esonomic benefits in the stages of 
design, development, operation and maintenance which will 


Seer a> approximately Sixty™ g2oyraphically @astz@buted 


i; 


Saces, Sacimia VING==a difscren- nix of- appkhicstion and 
terminal requirements. 

Perch ss tine, The oPLECe pEocessors are planned to be 
co-located with the host Burroughs Medium System at 2ach 


St9ck Point (SP) activity and wit e VEUSzOugnS amd Unsavas 


{I 


Syseems et Ehe Inventory Control Polats (ICP's). The SPLIC2 
Peogece proposes a distinct division of processing Eespornsi- 
Mec scs §Called a "forezround/background" concept. The 
Sbecreaeteground, utilizing a standard minicsaputer hard- 
ware and software se+, will serve as a front-end processor 
fer the Burroughs systen via a LOt2i Area Natwork (LAN) 
Snterface and will hanil2 communic2tion lines as well 435s 
EMpeert the interactive op2rations. This interactive <rans- 
action processing support will be ascomplish2=d using the 
Terminal Apvlica<ions Procassing Syst2n (TAPS) data ccmmun:i- 

cation terminal managemant for both on-line ard host 
Peoceso-ng cetminals, and networking communication logic for 
Nevy-wide distributed and sateilits activity capabilizy. On 
Sacommenoce | background “prosscessor (iaitwally the Burroughs 
MeqgeumeSyscem Somputers at each Stoc<c Point), the functions 


erformed will includ= large volun updating of master 


ro 


rm 
t? 
}- 4 
(p 
7) 
= 


@eeseing hard sony Teports and other furccions not 
a 


ctive immediate response access. 


BameedesotS OBJECTIVES 


fem one Of ©he SPLICE project wes inwtiated a2cmeks 


NavaterOscgraduate School, Monterey, Californi at the 
request O= Moe, to develop nd desiga suggested 
Pabeeeet Ves De SPLECE Local Area Networks. The purpose of 
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this thesis is to examine these alternate design specifica- 
pO Smeandsthauea te What integration tonsiderations have been 
mét and those areas +hat remain to be addressed among <hs 
various functional modul2s that have been developed in 
Sao PpOLt OL DOth Intranetwork communications occurring wi¢hin 
the LAN itself and internetwork comnunications between the 
LAN and the Defense Data Network (See Appendix c ). 


C. BACKGROUND 


The implementation of S?LICE as proposed by NAVSUP 
BembeGe=u aq clghtly coupled architesture whith utilizes 4 
feoweemata zed *ecomplex Manajear™ concept. The complex manager 
performs all required cooriination between the SPLICE system 
Conpenercs, OF Eunctions. Eight of these software functions 
have beer identified for devslopmant *o support the SPLICE 
concept. These functions ire Terminial Managem2at, Terminal 
Applications, Data Set Aanagement, Peripheral Management, 
Baetchi Appliceticns, Complex Management, Si Ock: Poon: 
Beet ame P=OCeSSOEF Support and Stock Point Host-Resident 
Sil DOrTt. Mier ise ese TUNneCtTOnS Willi provide an applica 
tion independent environment for LAN processing, while the 
ese cvO SUpport the Stock Pega, “HOSt> Saeerfacs fo7 

Foregrournd/background comnunication. It should be noted hers 
wie new ene ice SPLICE design, 75 Ole ri nod Ssleeene Seles 
SyoteMemopec- f2cati:ons [Ref. 2] ani the SPLICE Software 
Design [Ref. 1] revolves 2round 2 predetermined desire to 
Hoses clemmecenrminal Applications Protessing System (TAPS), 
Weeem 2S SGUE=entiy in @xistance 31t various Navy Stock 
PoLvits. TAPS is desijgied 2Oe to Love Communications 
Management (CM), Application Manajyement (AM) and Dat3 
Management (DM) capabilities necessary for the Navy applica- 
ti0n Systems to support on-line interactive query ana updates 


processing on the foreground complex. 


11 





The alternate SPLICE Functional design approach «ake 


J 


Wepe ae the Naval Postgsaduats Sshos5l is diracted towards 
fessognang= ene Logical Or virtual Local Area Necwork fs, 
thus ersuring that functional reguicements are satisfied 
{Ref. 4]. This is accomplished through the development of 
bumectaemal Moduies and their characteristics and the deter- 


Hee@at ton Of communication orotocols necessary to support 


then. The need for 2 somplex maazger is eliminazed by 
providing the nacessary control-structures for a fuliy 
Gas tributed LAN. The ability to move a functional nodule 
masme one fLuncticn2l ndd2 co andth2r will provide higher 


system availability than in the cas2 of fixed assignment of 
EuUsctional modules to physical nodas. THECUguUaE che —o ope 


G@istribution of functional resources across the nodes of the 


LAN, the failure of any one node would be transparent to the 
user anda higher degr22 of overall LAN reliabilit aS 
provided than would axist with ths use of a centralized 


complex manager. 
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II. LOCAL AREA NETWORK AND FUNCIIINAL MODULE OVERVIEW 


A. LOCAL AREA NETWORK (LAN) DESIGN 


A LAN has been defined as 2 data communication network, 
iyeomcally a packet comWanicafion network, Pema ed aq 


geographical scope {Ref. 5]. 


Basically, local area aetworks provide for the intercon- 
nection of data processing and -couputing devices Ilccated 
Within a tlimited geographical ares. They 2r2 primarily 
@aimed at providing a communications means for processes 


Beoceiemmenrn the MNULct pls hosts woaich connect +3 the network. 
LANS have been installed and implenented in various forn 


PoE 2 MUL=AXstude of functiras, and have experisnced v 


ray 
ty 
ba 
( r ] 
Le | 
Q 


degrees crf success [{Refs. 5, 7 }. 


Due to the future increases oF somputing dévices at “ha 
Navy's Simopivy Points and Inventory Control POLn=S, 
Peaewoeweng Of the devices within the iocal aréa offers =the 
Beeen ete. <O Gtficiently share avallable resourses. A local 
PemvenEw es r= tute Capable 52 providing compatible jiantercor- 
recuponeor vVatious terfinals, date processing dewices, Worl 
Pas cesscus, gateways to other conputer networks and of 
Wibevet!y sany type of diyztel conmmumecatzonedewice, cam 


n 
provide an extremely flexible and highiy creliabie environ- 
Benue to: SPLICS cont2zgquret: ons. 


MW @ajot advantage of locel are2 astworks in general is 
E 


10) 
a 
x, 
O 
| 
ox 
Q 
fv 
| 
U) 
G 
se 
oO 
©) 
ry 
ct 


ena, ~orce implemented, the local arean 


Deatiecc sy any ype Gf System tMansieponm. Anothes ségnmrée- 

Game agpect of a well-designed local netwotk is tha® *t can 

iooresc lOng-ttam, vendor -sadep]endsat transition strategy. 
e, 


is 





PoGal nee works do create certain problems that aust be 
considered, however. Provisions aust be maiz for speed 
Matching between the local area network and the long-haul 
network. In this particular instancs, this matching must 
occur between the SPLICE LAN and the DDN. It can reasonably 
be presumed that the LAN wili have a much higher data rate 
than the DDN. Thus, when a large nunber of packets are sent 
meeo the LAN to reach their ultimate isstimation through che 
DDN, packets may arrive at the gateway much faster than «he 
gateway is able to pass them to the DDN. A nechanism is 
reguired to prevent the gateway from exhausting its buffer 
Sogoee Aaditionadly, the virtual cirrtult protosal in the LAN 
(Weer be Compatible with chat of th2 DDN to allow for easy 
trams lation. 

One of the basic elenants which one must consider when 
dealing with LAN design is the topology methsd used for 
network interconnection. This issu is an important one in 
the performance of the LAN and is presented more fully in 


the follewing section. 


WwW 


Be. BUS TOPOLOGY 


Network topology is the arrangenent of digital devices, 


pammenmredes. telative to the iLntsarconnecting nedia. In «che 
recent evolution of locai somputer networks, séveral topolo- 
gi2s have emerged. The SPLICE reliability requirements (as 
outlined in the Functional Description) preclud2 a system in 


which the network can be nade inoperative by a single compo- 
nent failure. SPLICE configurations will also be subject *9 
changes over time. Thus, SPLICE requires a topology which 
provides high resilience to single component failure whils 
also allowing for syst2m growth ani reconfiguration. For 


these reasons, @ bus architecture was chosen (Ref. 8]. 
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Rie wegucea’ bUS Contiguration is an interconnection 
Sea cme Ttiwhech alin netwock computers or nodes are varty “tS 
Ss 


aq sanglie cOMM#inications channel which is used in 32 mes 


oh age 
Om packet switching mode. The chann2l may be a singie wire 
BeeemoewncOaweal Cable of even aepulti-wire corduic: il 


Mole-to-rode cOmunications takes olace cver this snared 
G Ss 


channel. The channel operazres in a broa 


dcast multivnle acces 
mode, similar zo that of an intern2l computer pus, where 2 
EE2nS@Vsston by amy of the nodes can be received by all o€ 
tnt remaining nodes in tn2= network. Ascess to the channel is 
Controlied by any of a nuaber of different time multiplexing 
Senemes. Tne gional bus tcpology fort local Qetworks has 
Semerel amnezert advantages over sther topologiss, ahclugirg 
Lew cost and ease or incremental network expansion. 
Tatoughput and message jelay characteristics are highiy 
@egen@er. onthe access control protscol used [Reft. 9]. sil 

K 


this shared channei computer communiration networ 
message can be transmitteli on the channei at a time. Bhus, 
it must be determined who tan transmit at any given time via 
some dis<ributed control mechaniem. Additionaliy, an 


Baesessima acchahism is Fequired *> aid in data ficw 


Beeeecer=s. As wiil be seen Gn 2 latsc diagram (Figure 2.1 j, 
piemele@ceice! desiagn of £h= SPRECE WAR orovides two types Of 
Perec] -2 .5US Which will wtwansfec she actual eoniica- 
=ions mnessages end 2 cS CERECL bus which wil carry 
Beimeerenakt ve “e2feic (suchas ctessurce allscazion, 2nd 
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C. FUNCTIONAL MODULES 


A Zunctional module is definei as one which vrovides 2 
Benetaizzed Eunction £55 s@my applications. As opposed to 
MavVang Hany sets of applications wmolules, ther2 will exist 
one set cf functional modalLes which can provide services for 
many applications. This design methodology was chosen to 
save time and money in system jeveslopment and implementation 
imRef.) 10 |. Simrceemery L£unctions ats commoa £9 
eppl™ca-100s, a2 grea= deal of duplicates work in the areas of 
System analysis, design, programminy, coding, ‘testing and 
Maintenance will result if applications modules are designe 
and implemented for each and every 2oplication. The func- 
Peoneal @module approach will saliminate this redurdancy 2nd 
mlacmucsil.a 23) <ha bettsr utzlization of computer resources, 
primarily memory and filé storage soace. This last bener 
memaue  <O the fach that the major differences in apolic:- 
Soromeusially exist. an tne input and output formats a 
applications parameters; they are not normally in the basic 

Meeroctons Of editing d2¢2, Maintaining files 234d generating 
G@2splays and reperés. 

Min = mem oeOse Gaeaduwete Sthicol des 
PeeeczeamemplLOacChelising farctional ms 
functional modules have o2en icen 
not ail have been completeiy de 


Tapie I. 


(D 


hese modules are dividel into ‘two basic ae i 


t-J 


Beer = Waeeeance = 5onS @such as. the txcansaction processing 
ES 


ct 


Memes, wand support functions which are those thet exist 


meke effective use of the precessiny nodules and the entir 


ft 


Rete ragure 2.1 -iliustrates the logiztal connections as envi- 
Susmed -reeghe SPLICE @GAN design. ine act. Wal copes gusa = on 


MewenWmes-Onea as Beime safiler to that shown in Figure 2.2 . 


ct 


* 
lola 
a 


(D 
(Dp 


It iilustrates 3 LAN CONESIUEs pn Ute eogiag 
S 


V) 
e 


A 


Minacomputers in addition to che maiaframes at SPLICse s 
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—_—) > > ae ee a See ee ee eee ee ee Ue see ee ee ol 


TABLE I 
Functional Module2s 


Local Communicatiors 
Net Orel COm@mMunications 
BoOW--=an dy Process png 
Terminal Management 
Data Base Management 
Dooce en  Sclye Goce 
eriphreral Maragement 
Secursty 
xecovery tianagement 
Network Management 


a — ee.” 


Foiiowing is an overview 2£ ths modules and the basic 
il 
tionship to other modules will be discussed in 
Sia0-~ers III and IV. 


Services they perfora. The major modules and 


e 
det2il in 


‘lee moce: COMMUN i Catt2as 


=— ess hn and Pess2=10n. Ine Washer gqee oe Sr 
management? 

Petes eomeomeone=Ol {f€rrorE 22tection, sorrecticn and ackrowl- 
edjemenc) 


—SAGMH@c= Secretion (imcludéngemessage 2scounting, handling o£ 
t ) 


Lost or Misdirtected messages and LAN shut 


- conversion of the Defense Data Network protoccls to LAN 
protocols and thé reverse 


- Messace assembly and disassembly 


ule 
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Figure 2.1 





3S. Prene-End Processing 


oe 2 eee Se ee eee ee oe eS a eee Ss = SS 


- Terminal and communication line buffering 
- code Conversion 

- Byte/word assembly ani disassembly 

- Tontrol message processing 


- Authentication 


- Message editing 
- Screer management 


- Virtual terminal operatis 
2. Data Base danagement 


=erale Creation end updating 
- Query processing and data retrisaval 
- Data dictionary creation and maintsnance 


PurebewGaralog Creat2:on and maintsnaace 


- Establish and maintain local and renote sessions: 
@- Within the LAN (SPLICE NMinicomputer processes) 
b. With local host (s) (tha nainframe processes) 
c. With remote host(s) (als) nainframe precesses) 


- Provide logical and physical nstwork addresses based on 
vVaiue of a Services Request Coie 


- Access control 


7. beripheral Managen 


Kv 


n* 


- Management of Unit Recori Input/Jutput (to include reading 
Caeags,enPlLiwii ang iines, and spoolbag filessfor Srepucte and 
Que pu Tt) 


PO secemnartacter Recognition or ark Sense BJuULpment 
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O34 Seeurity 


- Provide poSitive user ijentification via passwords 
eon ero lait hOr 1Z4tion Verification 
Peeeeyde SrOr FTecOonSceruction Of critical data 


-wesev=de auditing facilities 


9. Recovery Managenert 


smmcecezye and react =O notifgcation of transmission ¢eErpors 
(existence of an error coniition) 

Swucimte:n LAN cepy or Network Diractory and updave it wher 
physical address changes occur 

- Notify the Network Management moiule and all functional 
modules nd processors within the LAN of changessin Lan 


sea tus. 
10. Network 


- Perform monitoring and neasuring of LAN pverfornance 
=sfValletS network perfornance and identify down or failing 
components 

SoaOhsro: amd comtrol LAN interfacs to long-haul network 
(DDN) 

- Regulate flow of packets betweer networks and pertorna 
Sonemeback= <0 SUPDPOEt this flow 

eo Tovwemowigca! catlure go zificatiz>n to nreodes ana hosts 
Sieocedemmonr LAN and provide LAN with infornation about 


outside nodes and hosts 


(D 


= Provide accounting capabilitie2s (ee resource 


eee l= Zat_on) 


21 











IIi. COMMUNTCATLONS FUNCTEONAL MODULES 


A. NATIONAL COMMUNICATION (NC) MODULE 


It 1S a common user requirement that a single terminal 
ani access port should be able ¢> access any computing 
resource that the user may desire -- aven if the resource is 
Gn eanocwher data network. Based on this requirement, thers 

Tises a user need to have data networks connectsd together. 
Alcthough from user viewpoiats tha requirement for intercon- 
nection is independent of the network technolsgy, ehas 2s 
not true from the implementation viewpoints. There are some 
considerable complications in connesting networks of rela- 
eavely ditferent technologies. Thess interconnections can be 

it2zwed primarily in terns of interfaces and network services 
[Ret. 1]. 

These can both be divijied on tha basis of the character- 
istics they possess - thos2 of datagram or those of virtual 
Gueecuilt. i-weeS fiom eane cS distinguish datagran and 
Wieeialecircui® services from datagram and virtual circuicz 


interfaces. 


1. Datagram/Virtual circuit 


(D 
ry 


A datagram interface allows the subscriber to ent 


7) 


wi 
patkets into the network independent of any o*«nher packet 


( 


2 


en 
which have peen or will be enterei. Each pack3t is handle 
V 


) 


Pecwal cipel.t. 7 @eecreac- 


(D 


separateiy by the network. A 


4 


( 


eguites an exchange of control information between the 
subscriber and the network for tha purpose of setting up 
e@ese=ce.ransias ion tables, s2ttingjg up routes or preallo- 
Srcmpiagurccaileces ;, Deeors any data packets are carried to ths 
destination. Das. am snad—-cto-snd Logic cicsule must be 


estabiished. 


Ze 
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& datagram 
accepted and treated by 


thers. Sequenced deiivse 


1S no guarantee that all datagrams will be delivered. 


be 


duplicate copies 


pacxets may 
paths, 

virtual circult service 
delivery of 
Se 


network on 


the packets 
Gurculit. 
the packet-by-packet 


datagram service. Any 
filtered by *he destination 


eeesesSubsecriber. 
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*nterface between the 
es 


4]. 


while 


both sides of 
service [{Ref. Packets 
backbone, 
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sach 


time, 
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which data from one rnetwore 
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pen TePeond LA protocols. 


mine ce, on 


Serve: 
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is not guaranteed. 
independently routed over 
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“ypically provides the host 
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Dewprovided 


To avoid 
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With advice from 
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packet switch before delivery to 


esau 
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Will provide a virtual 
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Messages from the DPNein the form of packets accunu- 
late at the NC. The message or fragmant (if the NC hes found 
meee ecssadry tO pertotn iragmentation on ‘the incoming 
message) is then sent to the destination module over «ke 
LAN. The destination module's logical address and its phys- 
icai aadress would have been recoried in the message (sé2 
Session Services Module) at the originating LAN [Ref. 10]. 

The task or broadcasting physical address changes +9 
tHe Varicus LANS must be accomplished and it is currently 
envisioned that the Network Management Modules located at 
PesOmweli handle this. Adjditidrally, each LAN must keep 


$)) 


copy o= the network directory and max? all necessary charges 
to the network physical adiresses as they occur. This will 
be done by she resident Retovery Management Moiule [Ref. 4]. 

Physically, the NC reslies in the Front-&nd 
eee scor, if Will perzozm host to vhost flow conkrol but noc 
Bente rnace routing. Messages will be sent 79 the nearest 
Packet Switching Node (PSN) Os Che) DDNGeeens  bErO basis. 
Since «he LAN speed will feasibly bea greater tnan chat of 
the DDN, the NC buffer could easily fill to capacity. On: 
ioamed cj hendling this potential problem is t5 only pernic- 
@ single message to be unacknowledg2d at a time (Ref. 4]. 
in a@@@ition, it will netessary to reserve buffer space equal 
co the maximum size messajg2 fragment that could be received. 
BY Utilizing these restrictions, message handling wiil be 
Gone aeeasunatorm fashion both sintra LAN and Enver LAs. 
SSmeoeepsOoplens cOUld rssult froW® the first = 


e 
however, and these will be discussed in the las? chapzuer. 
3. CP 


AS previously neantioned, GP is Ene == mas, 
MNeeweetO=--OsS= PrOtocoOt in the DDN. Ah oVvetra 
TCP can be found in MOVend x os ho 
G@naracteristics ate reiterated here: 


- Host-to-Host protocol 
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emcs tdcrt 2n the [SO Transport Layer 

- Messages delivered in sequence 
~eaedtcal £uL’-duplex connections 

- Sequence number assigned to each ottat 


= Nessage sequencing and asknowledgenents controlled by tims 


O 
f= 
ct 
" 


us2rs 
metomaow Oriented rlow control 
- Destination TCP reassembles messaga2 segments 


- Mandatory that acknowleijyements D2 sent 


Only those aspects of the [C? which are necessary <o 
convert messages from LAN to DON format and vite versa will 
be implemented in the NC. The TCP commands which will bs 


impiemented in the NC are as follows: 

Soe tN 

- Active: Begin procedur® to synchronize connection 

- Passive: Listen for an inconing signal 

(Respective modules will be notifi2i by their local and 
renote NCs when a cconnection has b2aen nade.) 

= S nN D 

~ sence Gata contained in the indicated user buffer on the 
Sermneceion indicate 

oe SC RLVE 

~ allocate a receiving buffer associatec with the svecified 
eomnection 

See LOSE 

- close the specified connection 

(Respective nodules will be notified by local and remoce NCs 
km tis COnMest ion Bs cidsied.} 

Zeta Lu 


=—OGts2n Gctatus Of Connection 
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(This command is not always implemented; however, it would 
be to the advantage of the SPLICE nstwork +o utilize ic.) 
= ABORT 
- causes all pending SENDS and RECEIVES +o be aborted A 
RESET message is sent to the remote [CP. Respective modules 
a@r2 notified by their local and remote NCS that the conrec- 
tion has been aborted. 

It should be mentisned here that the activity of the 
TCP can be characterized as responding to events. The events 
Demeeemeonead above fall inte the cscatsgory of uSer calls. 
PeoGessing 1S dene by th> TCP in 2sponse t9 each of the 
events that occur. In many cases, the processing required 
Wee pend On the stats 35£ the connection. 

4. Network Layers 

For sending and raseiving nessages on the DDN, all 
seven network layers as iafined in the Reference Mcdel of 
Open Systems iMicmesconnes t2on  {I51) propos2d by the 
International Standards Organization (ISO) (Ref. 12] will be 
used. See Table II. iment Cr -£ GmMat Puers, 2oguwii..pes 
provided to tne DDN by tha NC modul2 whenever communication 


on the DDN is necessary. 


5. Addressing 


The TCP us2s port 
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~~ ame che oe 
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TABLE IL 
ISO Layers in DDN Conmanication 


Layer Hodulis> 
Application Application process modules 
Presentation T2rcminal Managenent 
Session S2ssion Services 
ECaNnspore TCP 
Network to be specified by the DDN 
Daca Link to be specified by the DON 
Physical to be specified by the DDN 


i gy AO cay AS cs ET my, a OR A A me, I a I a I i, 


ee | 


[ 
| 
| 
: 
| 
| 
| 


necessary. It is envisioned that processes may "own" ports 
mm~Eiaecmmec oy Cap Only z2Ritzate connections on the port 
that they own. A connection is spacified in the OPEN call 
by the local port and foreign (destination end) socket argu- 
mens. After the connection has been openei, the TCP 
supplies a iocal connection name by which the user refers t9 
the connection in subsequent calls “Ref. 23). 

iene SELTCE LAN, we the odfrt identifier will corze- 
Seoradesron tne Logical addr=ss of = functional omoduis. The 
Meewerk eda sss Corresponds to that of a physical processor 
MmuneGh one module resides. [his will allow f9c thepélex:- 
Domenty and Nobility of moduics, siace logical addresses do 
Eee.) Charge, whereas physical addresses are subject <9 
change. Beth +ypes of adicesses will be necessary to acce¢ss 


Geeisececula> EuUnccional module in th2 SPLICE network. 
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Be. LOCAL COMMUNICATIONS (LC) MODULE 


The LC module wili also use a2 virtual circuit service. 
Meow tl be possibile to set wp a virtual circuit between any 
two modules. The circuit would b= implemented by creatin 
tebles in the Session Services module at both the receiving 
and sending ends of the connection “Ref. 10]. The VissweL 


circuit can be establishzi betwean two functional nodul2s 


Pes sd@ing in the SPLICE Winicomputers and also between 2 
pimeerenal Woduls rcesidiing in a SPLICE minicomputer and 3 
functional module residing in 3a main frame. 


1. Network Layers 


Milcm@ler CEOLOGCOL, » as Lt 2S currently specified, “=5 
more complex than necessary for us= ina local area network 
Sen as SPLICE. in adit ten, maasurements of the TCP 
feet. 23] indicate that it has very poor throughput compared 
tc a high speed (10Mbits/s3c) bus such as the one propossi 
Beeeehe SPLICE lecat area network, ani thus will not provide 
optimal ZLocai communicatioa performaace. f the entire ICP 
feeeinc udeqd in LAN communications, many 2xtra Functions 
not needed would be unnec2ssarily inplemented. EEUs be 
best approach seems *9 be to utiliz® a subset of the DDN 
meee ees = Cuit protocol, Bees FS ClLOSs. Sede Te Puscs 
possible, but which specifies cnly those portions needed by 
mpemeaiee Ln this manner, transSiation between the two proto- 
Soueme se simplified and protocol conpatibility is provided 
MienOUt the hecessaty of designing t#9 protocols [Ret. 5]. 


LOS econ Nate, as shown in Tablis 


vy 
I 


Overall, a much 
eels be used £Or intra Can Sdtmunication than that of 
miementeaze £SO mcdel. Th> LAN will not require the détazied 
services normally provid2i by the Transport and Network 
Layers (Ref. 4]. The Presentation Layer functions wili be 


implemented in the Terminal Management module. iI2 will 


fe 





ee 


TABLE III 
ISO Layers in LAN Conmunication 


| 
| 
| 
! 
| | 
| | 
Layer Yoduls | 
: | 
cae ; , 
| Application Application process modules | 
| Presentation T2cminal Management | 
| 
| Session S2Ssion Services | 
Pera | 
Data Link Eos da eee Onmnuni cations | 
: + . 
| Physical hoc alveconmunicatzions | 
| 
| 
| 
a 


@eseuL Gata Crom the application process and convert it to 
the designed LAN standard format. Tt will also accept LAN 


formatted messages and -sonvert th2n to the appropriates 


GE Gae-On vrocess format. A terminal user would b= 
Pom=cge=eq an "“applicavion process" in this conversion 
Stavit y. 

The end-to-end virtual circuit connections (the 
reyoca Ll communication linkage between two Punecceeona) 


ec 
modules) andthe fragmentation of completes messages can be 
implemented in each of tha functional mod 

having them nandled by a [ransport Layer [Ref. 4]. by ee: 
faeces a steset Of th= DDN vartaal circuit protocol { 
would be used, as previously descrioed, and the need for 3 


compiete Transport Layer would be slininated. 


Ae, 





2. Addressing 


To enable implementation of the architecture which 
hes peen described, it will -requir2a that logical addresses 
be assigned to the funstional nodules which will bs 
contained within the SPLIZE minicomputers and to the func- 
tional modules which currently exist in the SP and ICP main 
frames. This last assignment will require the iientification 
of programs or packages in the main framesthat make up 3 
fieecionel module. The identification of 259urces is 3 
central issue in the davaiopment of distributed systems in 
order to providé¢ location ind2pendence and the possibility 
of having multiple copies of the same functionally named 
resource within the LAN [Ref. 10]. This location indepen- 
dence should permit end us2rs and applications proarams the 
ability to eccess and manipulate data regardless of whether 
it resides locally or at another noie on the LAN or at any 
remote rode in the SPLICE network. [9 support this location 
transparency, it will be necessary to create and maintain 2 
Pepe wh -Cch will provid= the physical address of a hardware 
imeeee wien che Logical addrass is Jjiven. This t2ble and all 
Hesoesery Maintainance funstions associated with it will be 
he responsibility of Session Services (Ref. 10]. Al heuga 
a table concept was criginzlly developed for a ring network 
structure (Ref. 13] it can be Simulated under other network 
Ssensceceures, such as Ethernet, which also uses a bus 


structure [ Ref. 10]. 
3. Message Formats 


LAN message fornats hav2 been designed Dy many 
authors. The basic structure providei here was designed in 3 
previous thesis [{Ref. 8], however, aiditional features haves 
been inciuded to incorporate other functions oerformed by 


eaoemecwork (Bert. 4]. Tf other funct®ons are requcced, cney 
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can be included at a latar date in much the same manner. 
Wher a module requires an acknowledgement, the acknowledge- 
ment will be piggyback2d ont> a data message if data is 
ready to send to the module. [f£ there is no data to 
transmit, an ordinary acknoowledgemeit message will be used. 


Requirements for control must bs incorporated into thi 


Ud 


method. These will allow for priority message notification 
as well as distinguish between new messages and acknowledged 


messages. It is planned that messages will be transmitted in 


one continuous stream of bits "Ref. 4]. ALEnougn fais wl) 
Simplify the communications protocol, buffer space aust be 
reserved fcr the maxinunm size message. Toe handls Long 


messages which could exceed the maximum buffer size of a 
functional module, fragmentation is used [Ref. 14]. A frag- 
ment is merely a part of a messaje. Deters isnstance, 
identification numbers must be provided for both messages 
Giese Ot Eraqnents. Following are illustrations of the intra 
LAN message formats and descriptions of the packet format 
cal 


(D 


lds. The data field length is allowed to vary. All other 


fields should be fixed length, however specifics lengths for 
these fields can be datermined after detailed network 
Gon t= guratlons and hardware Sp2rsifications have been 


estadlished (Ref. 8]. 
Ga, “aha Gg 


The flag fieli is a bit pattern which signifies 
the beginning and ending of a messajy2 or mess23ge fragment. 
Meemoedanning flag field is also ased to synchronize the 
receiving processsor with the intoning bit stream. This 

feepechould be Ghosen sach that its length is suffictent 
MmEPOce eve "dent: ficationyanies-s Jistortion jue to coil:- 
Sion with another transmitter's flay is easily discernable 
by collision detection jevices. The us= of the flag sequence 
Mmeam~eatomeor SOn=EOL information that occurs between flags 


must be prevented through use of a bit stuffing necnanisn. 
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LAN Message Format. 
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of messads 


trcansmitted. The major message types are as follows: 
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Cc. Date and Tine 


This provides the day, month, year and 24-hour 


clock time of message transmission from sender. 
d. Destination Ajiress 


This provides the logical and physical address 
G@= the seceiving module. [t will inform the correct moduls 


tO copy the rest of tne bit stream ani continues processing. 
€. Source Address 


This provides the logical and physical address 
Of the sending module. It is requir2zi for proper addressin 
of acknowledgements ani communications control information 


which must be maintained. 
if. Number of Fragnents 


This provides the numb2r of fragments contained 
in a message. It is usei primarily for message sequencing 
and for acknowledgement sontrol and 2lso by the receiving 


Demile 202 allocating buffer space. 
g. Message Number 


This is the sequential rumber assigned <0 each 
transmizczed message. If the message being sent is an 
acknowledgement, the nunder of the massage being acknowl- 
eagedewouldspe placed in this fiali. This numbec is reser™to 
Zéro on @ periodic basis. Each modil2 will be responsibis 
BOGS ceaaniag, LeSétting 2ni incrementing this count. In this 
méaner, the receiver will always know which message it 
Should rext receive and the sender will know which message 


nunber should next be acknowleiged by the receiver. 


sic) 





h. Fragment Nunber 


This is a sequential number which is assigned to 
each fragment that belongs to a message. This number will be 
reset to zero by the sender as soon as the first fragment of 
@onew message is ready t> be transnitted. Each module is 
responsible for setting, resetting and incranenting this 
count. In this manner, the receiver will always know which 
fragment number it should next receaive. (The nessage number 
will be increased after 211 fragments have been received.) 
The sender will know whic fragment number skhouid be next 
acknowilecged by the receiver. The first fragment will be 


humbered zero. 
2. AcKnowledgemeit Message VYumber 


This provides the messay= number that is being 


acknowledged. 
j. Acknowledgement Fragmeat Number 


This provides the fragment number that is being 


acknowledged. 
k. Data Length 


Rie Swiseldeprovides  th= number of bytes ~=nean> 
data portion of a message 9r message fragment. If no data is 


Meena scene, this field can have 2 value of zero. 
>. Services Request Code : 


This code will iniicate which service is being 
requested Dy a process. (Sudtameisstaleve. Leso5d, Bupdac- 


mocOrd, CGCic.) 
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Me Dawa 


mremdaca fleldeeconcains  <he anfornmeat:on <+o be 
delivered by the network. All other portions of the nessags 
neader ar2 stripped fron tae message when it arrives at ths 


receiving module. 
we REbOnr Check 


This field contains th2 Cyclic Redundancy code 
(CRC) which is a checksin computed by the sender. Lt an 
error is detected by the racsiver, ti2 fragment is discarded 
by the receiver and will 29t be acknowledged. A match indi- 
cates that there are no errors ani the message will be 
accepted by the receiver and acknowledged. If sender does 
hot receive an acknowledg2ment after an appropriate amount 
Gtwcame, it will assum]? 1ad>n-receipt and retransmit. If the 
second attempt at transmission fails, the Recovery 


Managemert module will be notified of an error condition. 


It should b= aoted that the Message Number and 
Fragment Number fields will be usei for data mnessages and 
OL rnon-piggybacked azsknowledgeanent messages. The 
Acknowledgemenz Message Number and the acknowledgement 
Fragment Number fields ar2 only usei when the acknowledge- 
ment is piggybacked ont> the data being sent. The Data 
Mendth, Services Request Tode and Data fields are only used 


when date is actually being transmitted in a message. 





IV. HANAGEMENT AND CONTROL F 


A. SESSION SERVICES (SS) MODULE 


The SS module provides the overall controlling mechanism 
muemiguctne Clients of the LAN functio1al resources, i.e. «hes 
Betmanel user and other functional resources themselves. 
Although the original design of Session Services [Ref. 10] 
makes a des tinge on between SO DenO. 1s ng SS and 
fMemeconct=sOlling SS, for the sake of simplicity and to avoid 
Semis. On, <=his thesis will consider Session Services as one 
entity containing all described characteristics. Regardless 
of whethe> a process is based on an interactive application 
or on an interactive session (via 2 LAN user's issuance of 
qu2ry language transactions), ther nust exist a controlling 
service to communicate and control the requirements of «h3 
user process(es) between itseif and the functional resources 
of the LAN. In order t9 2stablish communication between the 


coitroilling mechanism, th2 user and the functional modules, 


(D 


a Simple request-accept message transfer needs +o b 
performed [{Ref. 10]. This serviztée request code in 3 
message, similar to a user reguest task, is used by SS to 
Obtain the logical and physical addresses of the functional 
moduie(s) Which will perform the c2quested servic:. An 
acknowledgement, indicating either acceptance or denial of 
session support, would b= sent to t22 requesting SS module. 
After this series of events has besn established, the user's 
process can communicate freely throagh SS withsut the need 
+0 reconstruct another session s2rvice. References to 
currently supported user sessions would be maintained in 3 
Sapte ance could be used to idantify tne validity of clien* 


access for servic Byeere LuUnct2o14al-.resoursce.. -SS “wail 











invoke the appropriate functional module which then accesses 
the user message in thé [Terminal Y4anageament buffer. The 
moiule returns the required data after interpreting the 
instructions in the user n2ssaje. It is the responsibility 
of Terminal Management +o present the data provided by the 
functional module in the format needed by the user [Ref. 4]. 
This entire process involves all the ISO layers (as illus- 
meteed in Figura IIfrI ) reguired to support intra Law 
communications. 

[Memeecrta np Eeqmests for Servics ffom a4 user process 

e, 


Begui=e Coordination and scontroi of multiple LAN 


th 


Upeczional 


ct 


resources, Session Servisas wili ensure that the request is 
appropriately broken down into its respective component 
service requests and that they ars serformed in the correct 
Seder. basically, SS operates through Terminai Management. 
This situation results from the fact that user process 
messages reside in Terminal Management during a session and 
it is the responsibility 2f Terminal Management to keep ths 


user infermed of all progr2ss associated with th2 processing 


O 


£f his request [{ Ref. 10J. SS issues the various messages t9 


the functional modules in support of this request. 


B. TERMINAL MANAGEMENT (I4) MODULE 


The purpose of the [4 module is to provide LAN users 
meehethe facilities for communicating simultansosusly with 32 
large number of processes spread dut among various systems. 
A terminal user might ne2i *o0 communicate with the LAN or 
With other local area networks (othec Stock Poiats) through 
the DDN [Ref. 10 j. Since the set sf functional modules in 
h 


r 
— 


cr 
iD 


this design approach ach provide Same basic service, 


aif fot seo tes en 


WY 
iy 


+he major place where applications 


the terminal screen formats. 
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Terminal handling has 2lways b2s2 somewhat of a oreblen, 
Since, while terminals exhibit rather similar characceris- 
tics, they can differ in very significant ways. In a network 

rohitecture, the problem is additionally compounded. Fach 
geese Muse support all n kinds of tarainals supported by each 
of the m hosts cn the network. Thus 3ach host must poten- 
peaeiy be able to Support a x na terminals to permit any user 
to connect to it. As can easily b? seen, this is fairly 
memo faciical. 

Terminal-oriented protocols ars jiesigned t> reduce «his 
"m x n" problem t5 a nanageable siz by establishing conven- 


mors £0r handling all the 2tninals on the network 


aL ie 


eects t>j. On= such approach £9 a terminal pretocol defines 
= 


@a Network virtual terminal (NVI) [Ref. 16]. In this method, 


c+ 
we 
(D 


Semmce —cermanat sid= 5f£ @ confection mans the output of 


. 
Ce 
— 


UW) 


}- 


meEWenal into the NVI fcrmat f5r transmission through 


eal 


(D 


Meewesn. At the destination t2rninal, the WVT format as 
Meppead 2£82O its local format for presentatisa. The user 
ends, as defined above, could be processes as well as phys- 
ical terminals. This approach has t12 advantage of avoiding 
MeemidlciayS and e£Eiciencies Of atteapting to synchronously 
Srare 2 Gata structure across 2 network. 

MREVNVT has several shortcomings, however, which must be 
considered [Ref. 15]. Poo Nie Odiec ton Of few  serpminal 
COu@enas OF primitives witicut moiifying the protocol means 
that each new terminal conmand will require a minimum of six 
Seects (octet = 8 bits) to be represented. Because ths 

of 


BeokOCOl is strieam-orient21, e2very octet *ha data streaa 


Picweepe scanned £0 find control sequences. Secondly, ior 3 
virtual terminal protocol (VTP) +o bs ee eae used in 2 
general environment, the virtual ctarnminal must be very well 
Gefined. Otherwise, projrams that ise the terminal in more 
Bemus. Ca ed applications such 2s iisplaying ard updatin 


momen 2 CRT Will not be 2bls ¢o9 format their output 


Che 





Geterministically withsut considerable knowledge of ths 
physical terminal being used [Ref. 15]. Ther2 is also ths 
possibility that not all physical t2rminais may be able to 
Bepvaice all virtual functions. AddLtionally;. for “a «wWimeee. 
Memgenerally epplicable, 1t must restrict itself to terminal 
munct LOnNS. 


European investigations into virtual terminal protocols 


have made two major contributions: (1) & well-defined 
virtual terminal and (2) the development of a model for 
attentions or interrupts [{Ref. 17]. The VIP defines an 


basic framework for tha virtual terminal, and classes of 
virtual terminals are defined that correspond t> the classes 
of real terminals available (e.g., szroll mode, paged, daza 
entry, €tc.). Each class uses the basic model and adds to it 
the facilities and structures required. Thus, the use of 
tecminal class avoids reguiring that all inplementations 
Sippere the most sophisticated terminal functions and allows 
the characteristics of avirtual tarminal to more closely 
resemble the real ‘terminal being used [{Ref. 17]. The 
European designs also provide commanis for one side (virtual 
terminal) to request sf the oth2r what optidas and what 
tange of parameters it sipports and for the requested side 
=O ETeport what it can support. 

There may be some limitations imoosed or the choice of 3 
PaaoiletpcOeOcOl, however, as it is currently planned for 
the DDN to use an ARPANET Telnat NVI feature (Ref. 22]. ia 
*#his case, the NVI protocol will be probably needed in the 
MMemodule to enable commuaication with remote processes cvéer 
the DDN. A Terminal Management gzneric module has been 
proposed [Ref. 18] whish attempts t> provide a methodology 
Poem uriiazing aVTP other than NVI and still maintain 


Geompat2oili<y with the DDN protocol. Tt dsp relemuna. euhas 


al 
proposal shouid be further exaniasd ip LO CSe Seon ayes 


Searaoas -y £Or the SPLICE local network. 
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C. DATA BASE MANAGEMENT (DBM) MODULE 


Although the LAN d2Sign provides for distributed 
eeieat Ol, i: does Wot provide for the “total distribu-icn of 
data bases within the LAN. There is, however, distribution 
between the interactive Data 3ase Management System (DBMS) 
in the SPLICE miniconputer and the Burroughs mainframe 
Daeeh-Oriented DBMS [Ref. 4}. Data bases are, of course, 
G@astributed over the entire SPLICE aatwork. The data base 
mgctelOLs, however, ac= centralized within each DAR 
peet. 0 j. This Will enable the local network to maintain 


Sao Becessary contftol and @ntegrity of filss, as «hea 

SeealLog, data dictionary and indices will be cantzralized. 
Mo's ceripuced Drescssseng Ssyst2ms continus to grow, 
database management systems will hav2 to undergo changes ‘9 
S Of She dest oLtputed 


be responsive to the special srequirenant 
n the situation of 


ci 
j~- 
i 


n 
environment. This will ba mest sviis 
mio 2OCcea. area” network [R2f. 19 }. Changes will be needed 
both in the service provided by database management systems 
and in the service implementation - the way it is packaged 
peewcceeaver sd. SyYStem £2sources Sannot be dedicated to 
Single functional modulas; EOpeear Vallety wo. . feasO1s, 
erpcludirg the need to utilize sommon information, they aust 
be shared. Rothnie and others [Re£f. 20] belisve that thse 
Byoe oO. architecture provided by S0D-1 is appropriate for 
@Gt-Vic_es requisfing access to 2 siagle pool sf information 
distributed over a wide y2ographical area. It wiii permic 
decentralized precessing for reasons of perfornancs, reli- 
Soemetey and flexibidaty 2 furctzon, and was designed <9 
Manage Gata bases whose storage is distributed over 2 


network ct computers. 


mowenena: [ Ref. 19] introduces the concept of a fils 
server. This is a special purpose software modules that, as 3 
fenamans would coordinat® conscurrant access t5 2 giveni£ilse 


4) 





mememultipie requestors. It can also support file SOD U=9G, 
catalog management and ini2x searching. In a DBMS, the fils 
server will handle the eantire database as well as files. 
Wich adequate fixed disk storage for highly active files and 
moveabie disk storage for less active files, it~ should bs 
capable o£ Super tilGmamenOoro dc ound querié¢ss and file 
Maintenance requests. 

eiesciy tCelating <o this concept is thatwat the backend 
database management system as discussed Dy Maryanski 
Peet. 21}. This system was originally proposed as a solu- 
one tC the problems of overloaded data processing 
installations. Database management functions are offloaded 
from the existing mainframe to an attached ainicomputer. 
Basically, database requests are presented to the DBMS after 
they originate in an applications program and are trans- 
mitted through the interface routiaes. When the databas2 
request has been complet21, the resulting datz and status 
information are returned tc the backend interface which 
initiates transmission of the results to th2 host. AL eS 
method dees have the advantage of freeing a substantial part 
or the processor's resours2s; how2v2r, it has a number of 
drawbacks as well. A major drawback is the performanc2 
penalty incurred by the introduction of the interface and 
communication software and the transmission time of the 
sitiec computer link. Additionally, code conversion will be 
Eeagieered fOr Mapping chacacter and integer data betiween 
different isplementations. Both of the concepts presented 
esmworriy Of further investigation as m0 their applica- 
been y so 2he LAN design. A recommendation for 2 pametcular 
ctype of DBMS has not been nade by provious studies (Refs. 4 
p10 vy, Sincs it was felt that stroager emphasis should be 
placed on the capabilities of a venior provided DBMS (i.3., 
aNeegrla = ¥, BeGOVeD Vr GLotl.Cndsy, query language, data 


Meeessanbedi-y, Secirity, 2tc.) tatasrt than on the specirac 
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model sezected. <Aithough 1 complete dssign for the database 
functional module was not developed, a number of management 
tools (for providing organizational support) and some of tha 
basic functions the DBMS shouii provide have been identified 
{Refs. 4 ,10 J] and these are briefly discussed below. 

Peebaca SUD=Langmage (DSL). consists of a Data Definition 
meanguage (DDL) for defining data objects (fields) and a Dat 
Manipulation Language (DML) Poe ween) peCeesceama ror dines 
Seycets. AS identified by the CODASYL group, the main furc- 
t29n Of DDL is to describe the content and structure of the 
database schema and subschema. Although all DBMS have a DDL, 
these can vary inthe extent to whith complex relationships 
can be expressed. The complexity and capabilities of <=he DDL 
should be worth careful consideration based on its appiica- 
fa9n by Navy Stock Points and Inventory Control Points. The 
DMLS are used to transfer data *5 and from the database. 
They can be accessed by cscalis from a procedural language. 
Mae Capabilities sf the DML will diractiy affect the appli- 
@2@e2O0nS programmer. Sincs ‘the DDL and DML are closely 
related, the functionality of zach yanerally isternines the 
dejyree of responsibility of both the data base administrator 
and the applications programmer. 

Database Query Languages (DQLS) are generally interec- 
eve 2p nature. O2venm colved “sni-user facil sles, DOL 
Sleeeiaenwes provide direst interaction with the dagabass 
schema and permit search strategies for data retrieval or 
updates by approved end users or the DBMS. With a user 
fee cnaly DLO,  wsers can 2s2rform ad 19c queries or can build 


Mecme commend f-. les fer repatitive datz entry, cetrieval an 


fa 


Validation. A fully implenented and varied DQL will greactl 


iN 


suppert the current and future information requirement 


nesded by the Navy Supply System. 
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a 


eee seCMmenealetics cover a multitude of areas, froa 
password security to image managenent software and d2tzabase2 
tuning utilities. Additional jiatabas2 software for +ext ana 
Geaente’ Gisplays, audit trail utilities, database develop- 
men aids, database reloading and reorganizing aids and 
database sizing and responsiveness aids are also available. 
These could prcve extremely useful in support of LAN 
requirements 
Data Dictionaries/Directories (DD/D) abe vitel-an 7 @s 
distributed data environment and they may be implemented in 
Bee Lic-y OG Ways. A data dictionary is used =o identify and 


derine tne data elements sontained in the database, and anv 


relationships that may 2xist between these data elements. I: 
indicates where data resides geographically ani what data 
az2 repiccated. It shouli t2ll who owns the data, whe are 
Mmeonms 9fC LOL the accuracy of the Hlata, who update data, 


Cd co sad the dita. The gata daimectory 
GezioRs PECgramis, LAPUt CE cepor=*® aoen- 

gmipiy job streams, but generally it supports the 
elements that were identified in the data 


Sece 2 Cnaly. 


mimes. (n=S cetalog should intluds Ellenanme, size, .physical 
Memsesseor Doth Eile and index, iocation of backup copy, 
access restrictions and format. The nodule sasuld also be 
@ple to retszeve records Sor display, change resords, deletes 
emer Jmicecmm seccrds ard print both recsords and sntizre fiies. 
MSG OS2herng a eecozrd, the TH motuls will route the <rans- 
action message <c the DBM module. [his Gaduv= FeLi iocate> 


m 
Mc Cemieve che recoOEG j§and send i= to 


é 
Managemert (PM) module for printing. T= a us2z2 desires ¢t 

BateowceEatc, tne DBM Motale Will have <o open the file Gor 
m= em edule. The 2M mojule will then access and soooi chs 
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_emomuGuetesOwn GiSk file. [t tan then print the file 
Mm chOut <Ying Up the rest sf the LAW operations [Ref. 4] 

Capabilities Should exist to oravent data integrity 
problems when multiple processes r232d or update the sa 
data. The system should also permit the use of high-level 
database user languages for 1223 @ectzmeevil, repo 
formatting ‘and searching for and updating «he data. 

Aithough the above suggestions i939 not cover every 2SD0ECr 
Sema DEMS components and functions, they do describ n 
fees Of Laczjlitces and capabilities which must be consid- 
ered in providing a completely distributed processing s = 
Boa wre LAN. 
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V. CONCLUSIONS AND RECOMMENDATIONS 


Pies reite shat the overalludssign of the LAN in terrae 
or the functional modules presented provides a qualitative 
and useable design effort for a diistributed Local Area 
Network. A number of issies still remain to be addressed, 
pewever, tO arnsurej that all functions have bean completely 
considered and developed. 

- Continued suppert of organizational needs is paramount in 
the design cf any LAN. If LAN operability can be terminated 
by the failure of any single nod2 (functional module), than 
the LAN has the potential to be highly unreliable. Soma 
effort should be expended on providing dependability through 
MEcenOodmmor CAQuplicatiol of cE#tical) data™ and critical 
BumetLOns throughout the LAN. 

- More effort should bea ievoted to the development of the 
Pou woduie and the DBMS. Careful consideration o£ the inter- 
relationships between the Stock Points andthe Inventory 
Control Points should be made in th> salsction of any DBMS 
to support long range organizational osbjectives. 

- Additional research should be performed in the areas of 
security and in the management of functional shared 
resources. The provision of seturity controls that ars tamp- 
erprooft may best be accomplished by designing them into thea 
hardware. - Although the soncept of having only One message 
outstanding at a time between a pair of functional modules 
on the LAN provides certain advantages (i1.¢e.,reduced buffer 
size requirements), there can be a significant drawback as 
well. Since a monumental share of the communications will 
be occuring between the Front-End Processor and the Terminal 
Management and Session Services moijules due t> the physical 


Gonmect:ons envisioned (sse Figure 2.2 ), it is quite 





reasible that this restriction on window size for «hs 
various modules could craate a backlog of messages fio 
bus. Tt is recommended that additional study be done 
determine whether or not it would be more efficient and 
productive t9 increase th2 suggest2i window size and allow 
more thar one unacknowledged messag2 to exist at a given 
time. 

- Backup and recovery are very important in support of 
eae oPLICE requirement. Aiiitional study should be performed 

e 


in these areas anda working Recovery Managenent modules 
Should be developed to aandls errs> detection within <hs 
LAN. 


A Security Management module shoald be developed after 
the appropriate appropriat= risk analysis has been performed 
Sompsovldqe =5r the impoctait considerations of security and 
privacy needed ina distributed systen. 

- A design for a Front-End Prosassor should be initi- 
eed. It is suggested that 2 programmable front-end 
Meoce=sSOt wotild be more cost effective in communications 
SeaezOlL and would proviie MOL ser hess DLS Meso tue ons 8) to 
changing communications reyuirements. 

- A menu for dialogues shouli be incorporated into 
Session Services to enable users ¢o more easily employ 
distant databases, Making inquiries, seaerchiag the deta, 
Gepetat=nrg reports, and, where idssirable, updating ani 
creating data. 

- A Peripheral Managen2n* module should be developed tio 
mom nesm@eed fOr URit record input and output contsol. M@Bhis 
minct-one! module will enable users t 5 print lines, haves 
Sees fedag and Spool fites for input and output. Thorough 
research should be done t> determins what specific requirte- 
MENtS may be required to neet current and future needs of 


muemotock Points and Inventory Control Points. 





A simulation model 


performance of the LAN 


should 


be designed to estimate th 


as design2i. Attention should 


particularly focused towards 


meansit time. 
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response time and messag 
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APPENDIX B 
DEFENSE DATA NEIWIRK I 


The following information is provided as a short summary 
of the Defense Data Network (DDN). fhe source document used 
is the Defense Data Network Progran Plan revised May 1982 
fret. 22]. 


A. GENERAL DESCRIPTION 


The DDN is designed t> be a single integrated packet- 
BEwiscching data network which maests DOD lata network 
requirements, both present ani planaed. The DDN takes full 
advantage of existing operational networks, Such as ths 
WWHCCS Intercomputer Network (WIN) aad the Advanced Research 
Projects Agency Network (ARPANET), for hardware, softwere, 
Operations and maintenance prosedures adaptation. Its design 
will be based primarily on ARPANET tachnology. 

To reduce development, Maintenance ani logistical 
eae err COStS, It iis planned to standardize components <9 
the maximum extent possible. These tonponents are switching 
noi¢ hardware, SWiecieag §n2de ~sattware, SCY PLO gEa piiue 
gevices, mini-TACs, host front-eni isvices, host interface 
devices and multiplexers. 

The switching node is a 301% Baranek and Newman (BBN) 


G//S Oe which is a misroprogrammed minicomputer that can 


cr 


meemde TEMPSST/HEMP procection. fhis is the most curren 


generation cf packet switrthing hardware using the Interface 
Message Processor (IMP) software. The C/30 is designed for 
unattended operation and requires n> dedicated personnel. 

1 


Potewest have 171 switching nodes located at 2pproximately 


85 geographically distributed sites. Thes2? nodes will 
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reside on military facilities and are secure to «4 nininun 
fewet~ or SECRET. The DDN will contain a numbsr of network 
Monitoring Centers (MCs): @ principle System MZ, an alter- 
Meo Pe, Tegional MCs in the Pacific and in Burope, and mics 
at each keyed community. The M=Os monitor <¢he network 


Seacue, Provide for fault isolation and diagnosis, suppor 


rh 


software Maintenance in the nodes and mini-TACs, and 
Maintain network elements information. 

Tae network is dssijgned *9 wninimize communications 
Sepecg=e s*nrcugh the use of error istection and correction 


Meshanisms. A Cyciical R2dundancy Check (CRC) of 16 bits i 


" 


asscciated with host messages on th2 access line and with 
PacKetS on trunks to hanile burst errors that tyvoically 
Seatewe = sr gddition, 16-bit shecksums are provided on an 
end-to-erd basis within the switch subnetwork and on 3 
Weeee=tO-USer basis via the fPransmission Control Protocol 
(eee) « The protection mechanisms used in the switches are 
pesOmmaetecei0h and™corzrss>tion hardware to protect against 
menory failure and checksumming of critical data structures 


ioe POrsc.OnS Of code. 


qt 


pec vediabe lity of at least 99% will be provided by tas 
S 


Metwertk tO any pair tf single-homed users that wish i 


> 2, 
conamunicate witha ezch ot ». Users will have the capability 
+0 enhance their availa by dual access (two 
) 


access lines to the same 


UV 
x 
\- 
() 
— 
= 
£9 
|) 
U 
bls 
wD 


Or by dual=hoping 


4 


fomcanetesaccess line fo Ewo switching nodes). Thee see = 


method provides an increased network availability of 99.95% 
and will be used for critica 


iWesubSc="Ders. 
OrigqznAat.ng hosts and ‘terminals can assign ‘*tatfic 
précederce levels which will taen b2 used by the switchirg 


noies and mini-TACS as Sei oe oan LCSeSounce 3b voca ion. 


4) 


frees" ar ene nGg nodes provide four lsvels of precedence, 
Mescmpeion of Lower preseiance connéestions, non-blocking of 
iE 


MOst imput and Ssarvakion of buffers and other <tracite 


=) | 





related data structures. The mini-fAC provides four levels 
of precedence, preemption of input IZP segments and reserva 
from Of input buffers. Category I (Flash and Flash Overrids) 
traffic has the highest precedanse level and w 
processed in a non-blocking node 2xclusive of all other 
traffic modes and volumes. 

A number of features are provided by DDN t9 ensure its 
Survivability. Ali DDN hardware will have HEMP protection 
mieecne £Orm Of EM shiecliing, line isolation and surge 
arresting protection. Uninterruptibl>= power supplies will ba 
provided to those selectei sites having no backup power. To 
Beco laraetec SYSEEM reconS<~lt ution, there will be Zive mobile 
reconstitution nodes equipped with MC capabilities. DDN 
utiiizes a dynamically adaptive routing algorithm to auto- 
Maticaily route traffic around songested, damaged or 
destroyed switches and trinks so ths system can continue +9 
mimGeion. There is also 3 dense trunking grid to provide 


rejundancy at all possibl2 points in the network. 


B. S#ZCURITY AND PRIVACY MEASURES 


1. Link Encryption 


The kS-84 crypto device is used on all backbone 
e2unks, Seas a@ecess dinss to classifie hosts and 
M2ni-TACs, ani on access lines to sites that act as MCs for 
he unclassified community. The link encryption provides 
Sul. pemeod trafic flow security protection by concealing 
Beat ieic pat cerns Of intetswitch traffic, and by concealing 
BHp@et Mons=-+or-ng reports, which coald reveal traffic anal- 

gs AGELOrmation. Teowall also protect ~MC-swichmcorezol 
@earkic £=Oom disclosur:. Tezcioe ane ch is sent —knon one 
remote host to another remote host is encrypted first by ths 
Internet Private Line Intarface (IPLI) and again by ths 


KG-84 (see Figure B.1). 
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End~to-~End Encryption. 
53 


Figure B.1 








2. Security Level Separation 


All DDN subscribers will ooerate at a specified 
system high security level. Separation of subscribers az 
different levels is proviiad by «he uss of IPLIs. Thus there 
foeeene ct ieast on IPLI key for ash different system high 
devel, and, at Minimum, one such logical subnet for each 
security level. The IP and subnet headers must be in the 
elsar for packet processiig within the switch, yet they 
PieeVade inieorMation about subscriber traffic patterns and 
Semer ac analysis inforgation is classified secret. This 

robiem is handled by iink encoryption of subscriber access 
lines and by ensuring that all switching nodes are TEMPEST 
B@erosed and in secur a@ilitary facilities. To prevent 
Meedelivery of ttarfic statistics by the subnet, each MC and 
meo= "fake" noOst in Sach switch that sommunicates with <he wc 
will be members of a logical subnet that includes only theses 
members. The requests from the MC that = Giofepwee(ate hil ore okioye. 
and ceperting of rome Suactseics will be protected using 


PEiayecogucmumre althentsesation protocol. 


3. Separaticn of Communities oO 


im 


Interest 


He 


Communities of interest ars subscriber groups which 
[eeerGesene ah acceptable ievel of risk *9 each other and 2) 
Bequseeaehigh level of interoperability. Ssoaration 9: 
coamunities of interest is accomplisaed through the creation 
pElogmesmEsibne:s by cryptographic means, by sofmWars 
eT Ol mes DON. FOr unclassii@ed sibscribers, the switches 
Deeede the vabaicty to dc¢fine iogical subnets which conzins 
Meteaccestowesonly =O th members 3£ that logical subnev. 
Mice legueal sulnets acs 2stablishs3? by the SMC. Curren viy 
the switches allew for up 0 16 such subnets, but this can 


be €asiliy increased <*o 32 9r 64. 
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Rigorous Separation for classified user communities 
is provided by IPLIs. AS mentioned earlier, there will bs 
meee cdccmone LPLIT subnet (collection of like-keyed IPLtTs) 
for each security level. At this time, a community of 


Mi~esest 15 Jamicted by policy to 128 subscribers. 
4. Individual Access Zontrol 


REESssS scomcrol t5 Subscribers facilities is the 
responsibility of the subscribers ta2mselves. The network 
Will assure, based on a2 number of special mechanisms, that 
hs access of One subscriber to. another is controlled with 
respect t0 authorized sacurity level and sommunizy of 
interest. Network facilities do not verify, however, that an 
-ndividual user (person or process) attempting to access 2 
Subscriber has valid Stess rights +o that subscriber. 
Access control to mini-TIAls is provided by physical accass 
control measures, as mini-TAC acrzess is only available 


through hardwire lines. 


5. Personnel Tlearans2? Reguirenznts 


All personnel with access to switches must be 
cleared to secret level due *o the traffic analysis poten- 
tial. This clearance lev2l also applies te all personnel at 
faseoMweS and RMCS. Personnel manning a MC for a secure 
subnet must be cleared to the level sf the subnet subscri- 
bers, allowing personnel access +9 the corresponding IPLIs. 
Crypto techniciars will b2 needed for keying the IPLIs for 
Seen community and for link KGs. The keying material for 
Geach IPLI community is available only at the IPLI sites. Ths 
keying material for the link KGs is 2vailable 3n a pairwise 


Bbes:S at the switch sitss based on switch connectivity. 





C. MAJOR HARDWARE ELEMEN?RS 


1. Switching Node 


Mleewsmccnang nNol= is 4 BBN C/30 packet switching 
processor in a TEMPEST/HEMP package. The C/30 hardware is 2 
multi-board, microprogrammed miniconputer with 64K words of 
Random Access Memory (RAM). [Tt o509 Pome. 8 fui rangero. 
Synchroneus and asynchronous I/O interfaces. The C/30 soft- 
ware is tne ARPANET Interfice Mtssage Processor (IMP) 
program. IMP software can be loaded locally (from 2 
Cassette) or by a downline load under MC control. The soft- 
Ware provides four major fFinctional capabilities: 1) Tanden 
(eere 2nd forwatd) traffic processiag 2) Host access and 
Piieegm cudecretfic processing, using a variety cf host 
aescess protocols 3) Moen) evan 8a dynamac- adaptive 
distributed routing algorithm that aeasures actual packet 
delays and routes individual packets along the least delay 
path Piewoule Orang and sontrol services. 


2. internet Privats Line Lnterftace 


Mmoeewe PLL 15 42 s2curity d2vice, currently under 
development, which supports the DOD standard IP protccol and 
provides end-to-end encryption. IpPLI is composed of three 
mipeesOnets UNn2=Ss a KG 34 cryptographic device and wo 
MC68000 based packet proc2ssors (ons on the red side and one 
on the biack side of the “5S 84). Two hardware interfaces ars 
provided on each side of the IPLI. Initiaily used for backup 
purposes, they will Later DEavide “LoL dual-homing 
topologies. 

The software in 2ath processor will b= based on the 
CMIS operating system being used for a variety of packet- 
Secon nd applications. It will have the basic functions 
nesessazy for the DOD standard internet environment and for 


Heameesomerad and Gentrol., ISP and oth2r protocols which exist 











above the IMP can be supported sinc the IPLI has no krowl- 
Pigemecterme = TGP and’ packet processing occurring at <hs 
Internet Protocol lower lavel. 


See = 


A mini-TAC is a tarminal access device that allews 3 
cluster of up to 16 synchronous ani asynchronous terminals 
tO access the network. It is logically equivalent to a 
network host, particularly in that it uses thea same hest- 
iNOS c DLOtTOCOLS. MifaivimkAG swnlt bs constructed around 2 
Motorola MC68000 microproc2ssor with memory, 16 synchronous 
Or asynchronous terminal ports and nultiple network inter- 
mace ports. The mini-?fAC will neet TEMPEST and HEMP 
requirements. 

The mini-TAC software allows terminal users <*09 
establish connections between their terminals and an arbi- 
trary host on the network. The software will nultiplex all 
of the terminal-host connections 2v2er a single TAC-IMP 
aGSess tine. Mini-TACs will communicate with other network 
hosts using the DOD standard TCP and IP. The Telnet protocol 
will be used to provide terminal l2v2l support. 

The mini-TACs will be design2i for unattended opera2- 
Seon esenadewiaill teguire no iedicatei personnel. Rd CG Onies on 
functions and hardware aad softwares fault diagnosis can be 


done remotely from the network Monitoring Centers. 
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APPENDIX C 


TRANSMISSION CONTROL PROTOCOL 


This appendix presents 3 Simple description of the 
Beanome sston Control) Protzscol. The information provided was 
obtained from the DARPA [ransmission Control Protocol docu- 
Ment of January 1980 [Ref. 23}. 


A. GENERAL 


Dies isanaies atom Contra 1 Protocol (TCP) is intended for 
us? as a highly reliable standard for the transmission and 
reception of messages between host computers in &@ packer 
Switched computer communisations environment. This internet- 
work environment consists oof hosts connected to networks 
which are in turn interconaected via gateways. 

TCP is a connection-oriented, end-to-2nd relia 
Peotoeol designed to fit into 4a layered hierarshy of pro 
GeLs@waech support multi network applications. I+t provides 
for reliable inter-process communication between pairs of 
processes in host computers attached to distinct but inter- 
connected computer communications natworks. The Gee ’Fta-s 
BntOumemtcaye-Cd ~protecol architeceure just 2bove a basic 
moaceneme > 1 OrecG!] {1P) Which provides a way for the TCP to 
Send and receive biocks of data, called datagrans, through 
multiple networks and interconnecting gateways. (See Figure 
Gal). 


Be BASIC FUNCTIONS 


Since the primary purpose of TCP is to provide reliable, 
securable and logical circuit or coanection service between 


Eaieseor Onoecesses the following facilities are required: 
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Fagure Cc. 1 Protocol Layering. 


By packaging some numbar of sctets into segments for 
transmission through the iaternet system, the TIP is able to 
meats rer a CONtinwous Straam of octets in each direction 
between its users. The derision to block or forward data is 
made by the TOP at itS OWN sToONnVenience. Users are also 
allcewed to submit records, called letters, for transmission. 
Gn this case, the TCPs will forwari and deliver data up to 
h 
al 


cr 
Ww 


record boundary (end-sf-latter) that was specified by 


ct 


(D 


sending user. 


The cP must be able ts recover when data is 
damaged, lost, duplicatei or delivered out of order bv 

znternet communications system. Momeecconplish this... ea 
octet transmitted is assigned a sequence number, and a posi- 


tive acknowledgement (ACK) is required from the receiving 


Be 





ier Wiens ieeawopicem: ed tite interval. I 


th 
ct 
ioe 
(D 
oo 
© 
os 
j * 
{Nn 
= 
O 
at 


rezteived, data is retransnittei. 

The sequence numbers are used by the receiver <9 
Gorpectly Order Segments arriving out of order and to al 
nate duplicates. A cheskstm is added to #ach segq#ent 
transmitted to deal with damage occurrance. This checksu 
verified at receiving ¢ni and all damaged segments are 
discardec. If the internet system does not become completsiv 
partitioned, Dupe verimerzoning [OPS widl be abie 25 


SecsOvVeL £EOM IDtTeErNet CoMRENIcation system errors. 


3- Flow Control 


IJ 


The receiver can Jjyovern tha amount of data se 
thea serder by returning a4 "winiow' with every ACK 
arcange of acceptable seyuence numbars beyond that of + 
last successfuliy received segment. In strean noc 
window indicates the numbar of allowable octets the sender 
may transmiz before further permission must be obtain 


2d. 
rad mede, the window talis the allowed amount of buffer 


r 


7 
no | 
ww 
Q oO 


~ 
-_ 
—=— ZW 


é the sender may consume. 
4. Mulsiplexing 


Mae wTGP Srrovades 2 set of aidzesses or ports within 


each host to permit many precasses within that host to us? 


4 


TCP communicaticn <facilitiés simultaneously. Thes2 are 


Gon catcenaceaquwith the network and 20st eddzess2s Ezrom the 


(D 


TNteEENnet COmmunication layer and forn a socket. Zach connec- 
pees mmreaiely 2dentzf:ed by a pair of sockets, so one 
SOoKet Bay be used in multiple connections. 

pte GOnNnmeceten Of ports to processes is t2tudepen- 
demre y hanadtsd by each host, however it proves useful to 
attach frequently used processes to fixed sockets anc make 


da@dztesses known t>) 235 ¢TS. These services can =hen bs 


ct 
2 
(p 
tn 
(D 
ry) 


accessed more easily. 
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5. Connections 


MePemamewr-Guatrsd by Doth ths reliabzidity and flow 
control mechanisms to initializes and maintain certain status 
information for each data strean. Thepeconb snes on Of stds 
information, which incluies sockets, sequence numbers and 


MendOw sazes;,e 1s Called 4 Connection. The pair of sockets 


jt 


macs a@encifics ~ Sens sides uniquely Specifies i: 
eonnecticn. 

tf two process2s wish +0 communicate, theic TCPs 
Micee f2rSt establish 2 connection. This 2S 2e¢cemplis aed 
eeEeOugh tne Zhitcialization Of the status infornation on each 
Siije. When the communicazion is complete, the connection is 
terminated or clecsed to frae the resources for other users. 
Since these connections nust be established between hosts 
over a somewhat unreliable internet tommunication system, 3 
handshake mechanism with clock-based sequence numbers is 


SU meomo Cem = aoneouls ah! tializeation of connettions. 


6. Precedence and Sezarity 


TieommisercseOmeeLe> ‘May indicate the. sscurzty and 
Poeceaence Of twheiz. sONnNnUNISation. Sance .net -alise tee 
modules will necessarily function in a multilevel secures 
environment, some may be limited t> unclassified use only 
and others may Oper2t= at only one security level. 
Provision is mad for default vaiues to be used when theses 


Features are not needed. 


C. MODEL OF OPERATION 


Peecesses “Seansmit di2ta Gy calling on the TCP and 
passing Euffers of data as arguments. The TCP packages the 
Gata from these buffers into segments and calls on the 

naztion 


n 
internet module to transmit ¢ech seyment +o the desti 
O 


Deere eresery ong TCP places th i1a¢ta ££ 
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the receiving user's buffar and notifies the rasaiving user 


SomssOl 2ntOrpmation is imecluded in the seghents used by the 


i 
mees £O ansure reliable orieres Gatactransmissi2dn. 


a 


Bach TCP has an internat protocol module associated with 


isa = 
7° 


Ss 


§-4- 


 t© pREovide ani PReecrtase to the local network. 


}- 


internet module packages IZP seqments inside internet data- 
grams and routes these datagrams #59 a destination interne+ 
module or intermediate gateway. T) transmit the datagran 
Piz Ougwetne = 1OCel RetWwOrEx, it i:s embedded in a local network 
packet. The packet switches may perform further packaging, 
Eragmentaticon or other dp2erations +9 ashieve the delivery of 
mens LOGai packet to the destination internet module. 

At a gateway between networks, “h2 internat datagram is 
“an Wrapped" rtSm @es local packet aii examined 9 detezaere 
cALOUCHMmEMen RetwoOrk ths intern 
nex<. The internet datagram is thea "rewrapped" in a a 
Dackecmemetapie <o the next network and routed to he neéxe 
Gateway yeos ©O < be fanmail Jestaination. 

A gateway can break up an internet datagran into smaller 


internet datagram fragments if neadsd to allow transmission 
m 


through the next network. To accomplish this, the garemay 
produces a set of internet datagrans, each of which contains 
a fragment of the originai These fragments nay be broken 


down again at intermediaca aateways. The tragment format is 
designed so that the destinati n 


sembie these fragments iat 


W 

O n 

O aL 

aqdestine vzor module unwraps the ssg 

(after fragments have been reas D 
P 


passes it to the destination Tc 


& shouid be noted that the Methanisms of TCP do hot 
precluce » eee Se ecne 1TGl 21 4 LoOnt-sid SEcecoscos, 
Mo@mewce,  2n Such a case a hest-to-front-end protocol! muse 
Pacvesdce rr aommerumiceiOGmaliey tO Support the type of TCP=user 


interface required. 
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